آیا مهندسی معکوس به مدل بزرگتری نیاز دارد؟

مدل‌های قوی‌تر چه چیزی را تغییر دادند؟

از آگوست 2026، من در حال بررسی میزان مهندسی معکوس یک عامل با دسترسی به یک برنامه و راهی برای بررسی کار آن هستم. بیشتر تجربه من از بازسازی بازی ها به خصوص Touhou ناشی می شود. همانطور که من مدل‌ها را تغییر داده‌ام، مخازن رکوردی از آنچه هر جلسه توانسته است بازیابی کند را نگه داشته است.

هدف بیشتر این کار بازسازی دقیق است: ما منبع نگهداری شده را تحت یک زنجیره ابزار تاریخی با نسخه های ثابت کامپایل می کنیم و بررسی می کنیم که آیا تابع هدف را بازتولید می کند یا خیر. هنگامی که مدل بعدی در جایی که کار قبلی متوقف شده بود موفق می شود، تغییرات منبع نشان می دهد که چه چیزی این پیشرفت را ممکن کرده است.

متغیرهای موقت به طول عمر همپوشانی نیاز داشتند

بیشتر منطق یک تابع حمله TH09 قبلاً بازسازی شده بود، اما کامپایلر همچنان نتایج موقت را متفاوت از نسخه اصلی ذخیره می کرد. مشکل باقی‌مانده این بود که این نتایج چقدر طول می‌کشد تا زنده بمانند و چه زمانی می‌توان از ذخیره‌سازی آنها استفاده مجدد کرد.

یک GPT-6-Sol رکورد جلسه این عدم تطابق را پس از آزمایش چندین ترتیب کد منبع معمولی گزارش کرد. وقتی GPT-6.1-Sol دوباره مشکل را بررسی کرد، یک فرضیه مفید در مورد طول عمر این متغیرهای موقت ارائه کرد.

این تابع نتایج موقتی تولید کرد و آنها را در موقعیت های انیمیشن کپی کرد. در C++، یک نتیجه موقت زنده می ماند تا زمانی که عبارت استفاده شده از آن تمام شود. گروه‌بندی عملیات واقعی در یک عبارت، آن نتایج را با هم زنده نگه می‌دارد، بنابراین کامپایلر دیگر نمی‌تواند از فضای ذخیره‌سازی یکسان برای همه آنها استفاده مجدد کند.

یک نتیجه همچنان فضای ذخیره‌سازی را با مقداری به اشتراک گذاشته است که بعداً برای بررسی‌های برخورد استفاده می‌شود. دادن این ارزش به طول عمر خودش، همپوشانی باقیمانده را حل کرد. پس از چندین آزمایش هدفمند، کامپایل مجدد تمیز از منبع تأیید کرد که تابع کامل مطابقت دارد.

من علاقه مندم که چگونه این کشف و آزمایش ها از یکدیگر حمایت کردند. فرضیه در مورد طول عمر اشیاء موقت به عامل هوش مصنوعی مسیر جدیدی داد. بازخورد کامپایلر به آن کمک کرد تا این فرضیه را به ترتیب کد منبع که مطابقت دارد، اصلاح کند.

یک نمودار کنترل جریان متفاوت

تابع دوم TH09 نشان می دهد که چرا آن جهت جدید می تواند مهم باشد. در اینجا، مانع این بود که چگونه چندین شعبه کار نهایی خود را به اشتراک گذاشتند. کار قبلی GPT-6.1-Sol بخش‌هایی از تابع را مطابقت داد، اما شاخه‌ها همچنان متفاوت از نسخه اصلی به یکدیگر متصل شدند.

GPT-6-Astra نمودار کنترل جریان اطراف را تغییر داد. مسیرهای اصلی اکنون به یک به‌روزرسانی نهایی مشترک و بازگشت منجر می‌شوند. در آن ساختار منبع، کامپایلر شاخه ها را به همان روش اصلی ترکیب می کند. تابع کامل مطابقت داشت و بررسی بازسازی جداگانه آن را تأیید کرد.

تغییر نمایش، فضای جستجوی سازنده‌تری را باز کرد. هر دو مورد دلیلی برای جدی گرفتن قابلیت مدل کلی به من می‌دهد: یک نماینده می‌تواند قبل از یافتن راهی بهتر برای بیان کار اطراف، برای مدت طولانی تغییرات محلی را امتحان کند.

در همان زمان، جلسات بعدی با منبع قبلی شروع شد و خرابی ها ثبت شد. این کار انباشته بخشی از مزیت آنها بود. تاریخ به ما اجازه می دهد تا کشفیات و بررسی های آنها را بررسی کنیم. یک مقایسه کنترل شده به تفکیک اثر مدل از تجربه ای که به ارث برده است کمک می کند.

این چیزی است که سوال را برای من جالب می کند. برخی پیشرفت ها از یافتن نمایندگی جدید حاصل شد. بسیاری از کارهای باقی مانده شامل آزمایش ترتیبات مختلف کد منبع در برابر یک کامپایلر آشنا بود. چه مقدار از این به توانایی استدلال گسترده نیاز دارد؟ یک مدل با کار مکرر با آن کامپایلر و کد چقدر می تواند یاد بگیرد؟

چرا یک مدل تخصصی هوش مصنوعی ممکن است خوب عمل کند؟

Touhou دلیل مشخصی به ما می دهد که انتظار داشته باشیم آن تجربه کمک کند. بیشتر کد بازی از همان نویسنده، ZUN می آید، بنابراین عادت های تکرار شونده یک فرض شروع منطقی هستند. مخازن با مثال‌های مفید این موضوع را تأیید می‌کنند: حلقه‌های مرتبط و ترتیبات کمکی فرضیه‌هایی را در بین بازی‌ها ارائه کرده‌اند.

وقتی کامپایلر را وارد کنیم، این الگوهای منبع خاص تر می شوند. تحت یک نسخه خاص و مجموعه ای از گزینه ها، تغییرات کوچک در منبع می تواند تفاوت های قابل تکرار در کد ماشین ایجاد کند. برخی از این تفاوت ها به طرز شگفت آوری مبهم هستند.

به عنوان مثال، در TH095، حتی نام یک متغیر محلی می‌تواند بر جایی که VC7.1 آن را ذخیره کرده است، تأثیر بگذارد. انتقال اعلان آن طرح ذخیره سازی را حل نکرد. با این حال، یک تابع پس زمینه قبلی یک الگوی نامگذاری را نشان داده بود که بر انتخاب کامپایلر تأثیر می گذاشت. این فرضیه امیدوارکننده تری را برای بازسازی Supervisor::LoadDat پیشنهاد کرد.

استفاده مجدد از آن الگو برای متغیر اندازه فایل، طرح مورد نیاز را بدون افزودن فضای ذخیره سازی ایجاد کرد. سپس تابع کامل مطابقت داشت.

این یک جزئیات بسیار خاص است که یک مدل هوش مصنوعی همه منظوره ممکن است زمانی که برای اولین بار با مشکل مواجه می شود از آن مطلع نباشد. یک مدل تخصصی برای این کامپایلر می‌تواند موارد بسیاری از این قبیل را ببیند و یاد بگیرد که کدام تغییرات کد منبع ارزش آزمایش را دارند.

این فرصت به ویژه در مسائل تطبیق نهایی که ما قبلاً رفتار را درک کرده ایم، واضح است. سپس می‌پرسیم این کامپایلر کدام ترتیب کد منبع معمولی را به دستورالعمل‌های مشاهده شده تبدیل می‌کند. تخصص می تواند به مدل کمک کند تا آن اشکال را به طور کارآمدتر پیشنهاد کند، در حالی که هدف هنوز تعیین می کند که کدام فرضیه ها باقی می مانند.

الگوهای مفید باید زمینه خود را حفظ کنند. TH08 از نسخه Visual C++ قبلی نسبت به TH095 و TH09 استفاده می کند. TH04 از یک کامپایلر متفاوت از دوران DOS استفاده می کند. بازسازی کد بازیکن آن به فرضیه‌های مختلفی در مورد الگوهای کد منبع و نحوه پیوند کد کامپایل‌شده به یک فایل اجرایی نیاز داشت. داشتن یک نویسنده یک انتظار اولیه را به ما می‌دهد، اما هر هدف به ما می‌گوید که آیا کاربرد دارد یا خیر. یک مدل تخصصی باید این زمینه ها را متمایز کند.

این تجربه در کجا باید ذخیره شود؟

قبل از تصمیم به آموزش آن الگوها از طریق آموزش مدل، به دانشی که قبلاً در مخزن نگهداری می‌کنیم نگاهی می‌اندازم. در مقاله قبلی، درباره تبدیل شدن آن به حافظه کاری پروژه نوشتم. این حافظه شامل درس های کامپایلر، همراه با منبع و آزمایش های ناموفق است که آنها را مفید ساخته است.

با بازیابی آن رکورد، یک نماینده می تواند با یک نتیجه شناخته شده شروع کند و نحوه رسیدن ما به آن را بررسی کند. همچنین می تواند از جایگزین هایی که قبلاً در همان زمینه شکست خورده اند اجتناب کند. نقطه شروع بدون تغییر پارامترهای آموزش دیده مدل بهبود می یابد.

هنگام بازسازی عملکرد TH09 برای ایجاد دشمن، یک جلسه GPT-6-Luna-max یک فرضیه را از کد منبع TH08 مرتبط گرفت. آن کد قبلی نحوه سازماندهی حلقه و مدیریت خرابی های داخل آن را پیشنهاد می کرد. شواهد خود TH09 جزئیات مربوط به بازی را ارائه کرد. بازسازی از منبع تأیید کرد که عملکرد کامل مطابقت دارد.

"مدل نمی‌دانست که ویژگی کامپایلر" و "مدل نمی‌تواند از آن استفاده کند" مشکلات متفاوتی هستند. بازیابی ممکن است مشکل اول را حل کند، اما تبدیل این واقعیت به یک نامزد مفید هنوز کار می‌برد. و اگر کد منبع کاندید شکست بخورد، مدل باید تصمیم بگیرد که نتیجه برای تلاش بعدی چه معنایی دارد. دانستن الگوی مربوطه تنها آغاز آن فرآیند است.

به همین دلیل، من یک مدل هوش مصنوعی همه منظوره کوچکتر را با بازیابی خوب در هر مقایسه قرار می دهم. ارائه همان کتابخانه تجربی به ما کمک می کند تا تشخیص دهیم که آموزش چه چیزی را اضافه می کند: تولید نامزد بهتر، تصمیم گیری بهتر پس از بازخورد، یا هر دو.

یادگیری آزمایش مفید بعدی

آن تصمیمات پس از بازخورد همان چیزی است که من بیشتر دوست دارم مطالعه کنم. در بازسازی عاملی، مدل توضیحی را پیشنهاد می کند و آن را در برابر برنامه آزمایش می کند. حتی زمانی که کد منبع نامزد ناموفق باشد، نتیجه می تواند احتمالات باقیمانده را محدود کند و آزمایش بعدی مفیدتری را پیشنهاد کند.

مثال موقت نتایج را دوباره در نظر بگیرید. منبع نهایی آن ترتیبی را نشان می دهد که کارآمد است، اما مسیر رسیدن به آن منبع حاوی اطلاعات بیشتری است. هر یک از آزمایش‌های زیر به شناسایی آنچه که هنوز باید تغییر کند کمک کرد.

آزمایش‌های منتخب از بازسازی عملکرد حمله در بالا، گروه‌بندی شده بر اساس آنچه به ما آموختند.

یک رکورد آموزشی که این توالی را حفظ می کند می تواند بیشتر از منبع نهایی به تنهایی آموزش دهد. هر تغییر پیشنهادی را به یک نتیجه مشاهده شده و تصمیم بعدی مرتبط می کند. حفظ تغییرات بی اثر نیز مهم است: آنها به عامل بعدی می گویند که کدام فرضیه قبلاً در آن زمینه آزمایش شده است.

من می‌خواهم مدل یاد بگیرد که چگونه از بازخورد استفاده کند. یک نتیجه خنثی دلیلی برای تجدید نظر در تغییر است. تغییر عدم تطابق ممکن است به دلیل دیگری اشاره کند. وقتی ویرایش‌های محلی آموزنده نیستند، عامل باید بتواند بازنمایی منبع را بازبینی کند یا شواهد را دوباره بررسی کند.

یادگیری انجام آن انتخاب ها مستلزم استقلال است. گاهی اوقات گام بعدی مفید، بررسی تماس گیرنده دیگر به جای کامپایل ویرایش دیگری است. یک توالی سفت و سخت از بازنویسی های مورد نیاز این انتخاب را حذف می کند، همراه با بخشی از رفتاری که می خواهیم مدل یاد بگیرد.

چرا مهندسی معکوس برای یادگیری تقویتی جالب است

بازسازی با دامنه مشخص محیطی عملی برای مطالعه این تصمیم‌ها فراهم می‌کند. با ثابت نگه داشتن نسخه هدف و کامپایلر، بسیاری از آزمایش‌های کد منبع بازخورد سریع و تکرارپذیر می‌دهند. عامل می‌تواند کد پیشنهادی را کامپایل کند، تفاوت‌ها را بررسی کند و گام بعدی را انتخاب کند.

یادگیری تقویتی می تواند این فرآیند تصمیم گیری را از طریق بازخوردی که دریافت می کند آموزش دهد. یک نامزد پذیرفته شده توسط یک چک تعریف شده یک نتیجه مشخص به ما می دهد، در حالی که توالی تلاش ها به ما امکان می دهد مشاهده کنیم که چقدر کار برای رسیدن به آن لازم است.

در حال حاضر تحقیقاتی وجود دارد که از این جهت حمایت می کند. LLM4Decompile مدل های تخصصی برای دیکامپایل را مطالعه می کند. AutoDecompiler با استفاده از بازخورد کامپایلر و اجرا، اصلاح چند نوبتی را آموزش می‌دهد. مطالعات آنها بر بازیابی عملکردی متمرکز است. برای این کار، من از آنها به عنوان نقطه شروع برای کار مرتبط یافتن منبعی که با خروجی یک کامپایلر تاریخی مطابقت دارد استفاده می کنم.

با این حال، برای رسیدن به چنین وظیفه ای به خوبی تعریف شده، ممکن است ابتدا نیاز داشته باشیم که یک تابع دارای چه منابعی است یا یک روش جدید برای مشاهده رفتار برنامه هنگام اجرا را طراحی کنیم. به عنوان مثال، در TH08، یک تفاوت برخورد منجر به نحوه مدیریت برنامه اصلی با محاسبات ممیز شناور شد. قبل از اینکه عامل بتواند یک تصحیح مفید را آزمایش کند، باید تعیین می کرد که چه چیزی را باید اندازه گیری کند.

این یک نقش دیگر را برای یک مدل به طور گسترده نشان می دهد: کمک به قابل بررسی کردن مشکل در وهله اول. هنگامی که آن چک وجود داشت، می‌توانیم بررسی کنیم که یک خط‌مشی جستجوی آموخته شده تا چه حد می‌تواند با آن برسد.

هنگامی که بررسی کننده تأیید اشتباه است

وقتی یک بررسی را برای آموزش به کار می‌بریم، دامنه آن هم بخشی از محیط یادگیری می‌شود. من چنین مرجع یا ابزار بررسی را اوراکل می‌نامم. حتی پاسخ تکرارپذیر را باید در محدوده چیزی فهمید که واقعاً بررسی می‌کند.

TH08 نشان داد که مشکلات می‌توانند بیرون از دامنه بررسی پنهان بمانند. بعضی توابع بازسازی‌شده با وجود ثابت‌های ممیز شناور اشتباه، مقایسه دقیق را قبول شدند. مقایسه‌کننده پیش از بررسی دستورها آدرس‌های جابه‌جا‌شده را تنظیم می‌کرد، اما مقدار اشاره‌شده را فقط وقتی بررسی می‌کرد که برای اعتبارسنجی صریحاً ثبت شده بود. ارجاع‌های دیگر به ثابت‌ها می‌توانستند بدون بررسی مقدار قبول شوند.

برای رفع این شکاف، یک ممیزی گسترده‌تر ثابت‌های نادرستی را در توابعی که قبلاً تأیید شده بودند پیدا کرد. در یک محاسبه، کد منبع بازسازی شده 1.0f را اضافه کرد، در حالی که کد اصلی 32.0f را اضافه کرد.

مدلی که توسط چک راستی‌آزمایی قدیمی پاداش می‌گیرد، می‌تواند یاد بگیرد که یک بازسازی نادرست ایجاد کند. ما یک مدل RL را با استفاده از آن بررسی‌کننده آموزش ندادیم. نقصی که مشاهده کردیم در خود چک بود. اما اگر از آن به عنوان پاداش استفاده می کردیم، همان نقطه کور بخشی از محیط آموزشی می شد.

یک تست عملکردی می تواند نقطه کور مشابهی داشته باشد. تحقیق با استفاده از fuzzing دیفرانسیل در دیکامپایلرهای LLM تفاوت‌های رفتاری را خارج از آزمون‌های ارائه شده یافت. بنابراین ما باید یک آزمون قبولی را بر حسب مواردی که انجام می دهد درک کنیم. به طور مشابه، یک تطابق دستورالعمل باید از نظر بایت ها و داده هایی که تأیید می کند درک شود.

قبل از استفاده از هر نوع بررسی تأیید به عنوان پاداش، آن را با نتایج عمداً نادرست آزمایش می‌کنم. من همچنین پذیرش نهایی را از کد منبعی که عامل هوش مصنوعی می تواند ویرایش کند جدا نگه می دارم. مدل باید با بازسازی صحیح برنامه، تأیید صحت داشته باشد. در غیر این صورت، کپی کردن یک آرایه بایتی از هدف می تواند یک سیستم امتیازدهی ساده لوح را بدون بازیابی کد منبع مفید فریب دهد.

بهبود یادگیرنده و بهبود بررسی‌کننده تأیید آن مربوط به یک مسئله تحقیقاتی است. همانطور که یادگیرنده در بهینه‌سازی بازخوردی که ما به آن می‌دهیم بهتر می‌شود، درک آن بازخورد نیز مهم‌تر می‌شود.

مقایسه ای که ارزش اجرا دارد

با انجام این بررسی‌ها، مقایسه را روی یک خانواده کار ثابت VC7.1 شروع می‌کنم. اول، من خطوط پایه را برای یک مدل هوش مصنوعی همه منظوره قوی و یک مدل کوچکتر ایجاد می کنم. افزودن دانش مخزن به مدل کوچکتر، تغییرات بازیابی را نشان می دهد. از آنجا، تخصص تحت نظارت و یک نسخه آموزش داده شده RL به ما اجازه می دهد بررسی کنیم که آموزش چه چیزی را اضافه می کند.

برای اینکه این مقایسه ها آموزنده باشد، هر مدل شواهد و ابزارهای هدف یکسانی را دریافت می کند. برای مقایسه‌های آموزشی خاص، مدل پایه و دانش موجود را نیز ثابت نگه می‌دارم. آزمایش‌های مکرر به تمایز یک استراتژی جستجوی قابل اعتماد از راه‌حل نامزدی که به طور تصادفی موفق می‌شود کمک می‌کند.

سپس دو شرط شروع را جدا می‌کنم: بازسازی یک تابع از دستورالعمل‌های آن، و بستن چند تفاوت آخر در منبع حفظ شده. یک مدل هوش مصنوعی تخصصی ممکن است در کار دوم عالی باشد در حالی که یک مدل هوش مصنوعی همه منظوره بسیاری از کارهای مورد نیاز برای رسیدن به آن را انجام می دهد. اندازه گیری آنها به طور جداگانه این تقسیم کار را آشکار می کند.

هر دو کار به نمونه‌های آزمایشی نیاز دارند که از آموزش و بازیابی حذف شوند. کد موتور اشتراک گذاری بازی های مرتبط Touhou. حذف یک بازی از تمرین همچنان می تواند عملکردهای تقریباً یکسانی را در مجموعه تمرینی باقی بگذارد. در عوض، من کل گروه‌های کد منبع مرتبط را حذف می‌کنم و پاسخ‌های تأیید شده‌شان را هم از داده‌های آموزشی و هم از کتابخانه بازیابی خارج می‌کنم.

برای این مثال‌ها، نتیجه، مطابقت‌های کامل و تأیید شده مستقل خواهد بود. بودجه‌های برابر برای پیشنهادهای نامزد یا تلاش‌های کامپایل به مقایسه کیفیت جستجو کمک می‌کند. اندازه‌گیری زمان و هزینه کل، از جمله کامپایل، نشان می‌دهد که آیا این کیفیت گردش کار کارآمدی ایجاد می‌کند یا خیر. هزینه های آموزشی باید جداگانه اندازه گیری شود.

هر دو اندازه گیری مهم است. یک پروپوزال ارزان می‌تواند منجر به گردش کار گران‌قیمتی شود اگر باعث کامپایل‌های بیشتری شود که اطلاعات مفیدی ارائه نمی‌کند. برعکس، یک مدل کندتر ممکن است اقتصادی تر باشد اگر آزمایش مفیدی را زودتر پیدا کند. مقایسه باید شامل این هزینه ها باشد.

شمارش نتایج پذیرفته شده همچنین پیشرفت متوسط را در چشم انداز نگه می دارد. یک TH09 replay-save نامزد امیدوارکننده به نظر می‌رسید، زیرا تابع کامپایل‌شده اندازه مورد انتظار را داشت، اما یک مقایسه کامل همچنان تفاوت‌های اساسی را پیدا کرد. تغییرات در نحوه چیدمان دستورالعمل ها توسط کامپایلر می تواند بدون حل مشکل اساسی، نامزد را نزدیک تر کند. چنین تشخیص‌هایی می‌توانند آزمایش بعدی را راهنمایی کنند، اما من هر پاداشی را برای «نزدیک‌تر شدن» در برابر بررسی پذیرش کامل تأیید می‌کنم.

من به الگوی این نتایج علاقه مند هستم. اگر یک مدل تخصصی هوش مصنوعی در یک خانواده کامپایلر آشنا به خوبی عمل کند، آیا این مزیت از تغییر زنجیره ابزار باقی می ماند؟ و هنگامی که هر دو مدل هوش مصنوعی بازیابی خوبی داشته باشند، آموزش هنوز چقدر اضافه می کند؟ پاسخ‌ها به ما کمک می‌کنند تصمیم بگیریم که هر نوع مدل در کجا مفیدتر است.

این چه نوع عامل هوش مصنوعی را پیشنهاد می کند؟

اگر مدل ها در مراحل مختلف کمک کننده باشند، یک ترتیب مفید ممکن است عاملی گسترده با دسترسی به یک مدل تخصصی هوش مصنوعی باشد. هنگامی که یک کار به یک جستجوی کامپایلر آشنا تبدیل می شود، می تواند مدل تخصصی هوش مصنوعی را برای نامزدها بپرسد. اگر نتایج منطقی نباشند، عامل گسترده‌تر می‌تواند به شواهد هدف بازگردد یا خود اندازه‌گیری را بررسی کند.

در آن ترتیب، تخصص به ابزاری تبدیل می‌شود که عامل می‌تواند با توسعه تحقیقات انتخاب کند. عامل آزادی تغییر جهتی را حفظ می کند که پیشرفت های قبلی را ممکن کرده است.

این به طور طبیعی از تغییر صنعتی که در مقاله قبلی توضیح دادم ناشی می شود. توانایی انجام آزمایش‌های بسیار بیشتر، نحوه سازماندهی کار را تغییر می‌دهد. همچنین دلیلی به ما می دهد تا بپرسیم کدام تصمیمات نیاز به قضاوت گسترده دارند و کدام یک از طریق تجربه مکرر با یک هنر خاص بهبود می یابند.

تا اینجا قوی‌ترین مدل عمومی جای خود را در گردش کار من پیدا کرده، چون مسائلی را حل کرده که قبلاً حل نشده مانده بودند. همین موفقیت‌ها مرا به بررسی دقیق‌تر فرایند ترغیب می‌کنند: چه مقدار به گستردگی توانایی مدل وابسته بود، و چه مقدار را مدلی آموزش‌دیده برای همین نوع بازسازی می‌تواند انجام دهد؟

مخزن‌ها راهی برای آزمایش سؤال به ما می‌دهند. من می‌خواهم از آن رکورد برای ساخت مقایسه و دیدن آنچه یاد می‌گیریم استفاده کنم.